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Introduction 

Realistic simulation of an aircraft cockpit in a 
flight simulator requires dynamic instrument panel 
displays that provide flight information to the pilot. 
These displays, consisting of dynamic lines, polygons, 
and alphanumeric characters, must be updated at a 
sufficiently high rate to realistically simulate actual 
flight displays. The displays for the Advanced Con- 
cepts Simulator (ACS) at NASA Langley Research 
Center are generated on the ADAGE Raster Dis- 
play System 3000 (RDS 3000). An overall descrip- 
tion of the RDS 3000 can be found in reference 1. 
Originally the display programs were written using 
straightforward sequential programming techniques 
in the IKON AS Display Language (IDL2). (See 
ref. 2.) IKONAS was the former designation of the 
RDS 3000. The resulting update rate of 4 frames per 
second for the primary flight display was insufficient 
for a realistic simulation. To correct this situation, 
the programming techniques, language implementa- 
tion, and hardware characteristics were extensively 
studied. Improved programming techniques were de- 
veloped and the language implementation was re- 
vised to take better advantage of the high-speed char- 
acteristics of the RDS 3000 hardware. The result was 
a fourfold increase in the update rate to 16 frames per 
second. 

Each of the three processors in the RDS 3000 is 
designed to perform certain specialized tasks. The 
main processor, the Bipolar Processor System (BPS), 
is the master processor of the system, which is nor- 
mally used to draw lines, polygons, and characters as 
well as to perform system control functions. The ma- 
trix multiplier (MA1024) is a slave processor that is 
designed to perform coordinate axis transformations 
at high speed. The Advanced Graphics Generator 
(AGG4) (ref. 3) is a second slave processor that may 
be used to draw characters at a higher speed than 
the BPS. Speed has been improved primarily by op- 
erating the processors and certain hardware functions 
in parallel with each other whenever possible and 
by revising the system microcode. The microcode 
revisions mainly focused on increasing the speed of 
character generation. Speed improvements here re- 
sulted from (1) using the parallel processing capabil- 
ities of the AGG4 and (2) using the AGG4 to take 
advantage of certain high-speed characteristics of the 
display memory that were not previously used. This 
paper describes techniques used to increase an- 
imation update rates by parallel processing and 
microcode improvements. A sample program illus- 
trating the use of these techniques is included as the 
appendix. 


Symbols and 

Acronyms 

k 

integer specifying increasing 
horizontal displacement, 
dimensionless 

n 

integer specifying the multiple 
of 32 pixels of the vertical 
displacement, dimensionless 

X 

vertical screen displacement, 
pixels 

Y 

horizontal screen displacement, 
pixels 

Acronyms: 

AGG4 

Advanced Graphics Generator, 
Version 4 

BPS 

Bipolar Processor System 

CHAR 

character command in the 
IDL2 display language 

CXBS 

channel crossbar switch 

FBC 

frame buffer controller 

FBM 

frame buffer memory 

GM 

graphics memory 

IDL2 

IKONAS Display Language, 
Version 2 

IKONAS 

previous designation of the 
RDS 3000 system 

IOR 

inserter output register 

LUVO 

color map and video output 
module 

MA1024 

matrix multiplier 

OBFM 

onboard font memory on the 
AGG4 processor board 

PING 

buffer area in memory 

PONG 

buffer area in memory 

RDS 3000 

Raster Display System 
(current designation of the 
graphics system) 

SR8 

system scratch memory 

XBS 

crossbar switch 

Display Generation 


Description of the Displays 

The primary flight display for the Advanced Con- 
cepts Simulator is shown in figure 1. The upper half 
of the display is the attitude display indicator (ADI), 


which provides the pilot with his primary flight infor- 
mation. Roll and pitch information is presented by 
the artificial horizon and pitch ladder at the center. 
Airspeed and altitude are displayed on the dial indi- 
cators at the upper left and right. Directional com- 
mand information is presented by the circular track 
ball at the center and a speed error is presented by 
the vertical bar to the left of center. Various com- 
mand and alert messages are presented by the char- 
acter strings; and horizontal and vertical errors, by 
the pointers labeled “H” and “V.” The lower half 
of the display presents navigational information in 
which the circular compass rose presents heading in- 
formation and various special symbols such as the 
small triangle and hexagon present navigational aids. 
Additional navigational information is presented by 
the character strings. In both displays some char- 
acter strings are stationary and some move about 
the screen; some characters change and some do not. 
Tracking indicators are displayed above the compass 
rose in the form of a diamond and a double square. 

The modules of the RDS 3000 that generate all 
the displays are shown in figure 2. All intermodule 
data communication is over the 32-bit IKON AS bus 
and several auxiliary buses. Video information passes 
over the video bus. All images are stored in the frame 
buffer memory (FBM), which has a maximum display 
resolution of 1024 by 1024 pixels by up to 24 bits per 
pixel depending on the amount of memory available. 
Images are read from the frame buffer memory by 
the frame buffer controller (FBC) and start toward 
the video output. The crossbar switch (XBS) and 
the channel crossbar switch (CXBS) work together 
in a manner analogous to a telephone switchboard to 
allow selected individual and groups of frame buffer 
bit planes to be displayed. The color maps (LUVO) 
convert the pixel information selected by the cross- 
bar switches to red, green, and blue (RGB) analog 
video signals for display on the video monitor. The 
host interface controls communication between the 
RDS 3000 system and the host machine, which is a 
Digital Equipment Corp. VAX 8650 superminicom- 
puter. The main processor (BPS) processes program 
instructions which are stored in the scratch pad mem- 
ory (SR8). Communication between the BPS and the 
scratch pad memory is over the IKONAS bus. The 
matrix multiplier (MA1024) performs matrix opera- 
tions required for coordinate transformations. Vector 
data to be transformed are stored in the scratch pad 
memory and communication between the M A 1024 
and the scratch pad memory is over an auxiliary 
bus. This auxiliary bus allows the transformations 
to proceed without interfering with other data trans- 
fers taking place over the IKONAS bus. The parallel 
processor (AGG4) is used for character generation. 


All data needed by the AGG4 to draw the charac- 
ters are stored in a small memory area on the AGG4 
board known as the onboard font memory (OBFM). 
All communication between the processor and this 
memory area is over an onboard bus, so the only time 
that it must access the IKONAS bus is when a char- 
acter or part of a character is ready to be written to 
the frame buffer memory. In contrast, the BPS must 
access the IKONAS bus to get vector and polygon 
vertex information and to write the resulting image 
information to the frame buffer memory. 

Display programs are written in an assembly 
level language known as IDL2. Commands in this 
language perform operations such as drawing lines, 
polygons, and character strings as well as two- and 
three-dimensional coordinate transformations, clip- 
ping, and perspective projection. Display commands 
are stored in the scratch pad memory and inter- 
preted sequentially by a dispatcher program which 
runs in the BPS. As each display command is in- 
terpreted, this dispatcher directs the execution of a 
block of microcode resident in the microcode mem- 
ory (MCM). Communication between the BPS and 
the microcode memory is by way of an auxiliary bus 
to prevent the loss of speed that would occur if the 
IKONAS bus were used. Several microcode files are 
included with the system and the one used is de- 
termined by the hardware configuration. New com- 
mands may be created and existing ones modified by 
using tools that are included with the system. These 
tools were used to revise the microcode to improve 
character generation speed. A compiler for IDL2 and 
a microcode assembler are used to create the exe- 
cutable files. 

Theory of Operation 

Animation of a display is accomplished by repeat- 
edly drawing new images and presenting them to the 
observer. These images are created as bit patterns in 
the frame buffer memory. Smooth animation is ac- 
complished by repeating this process at high speed, 
typically at least 16 times per second. To prevent 
the observer from seeing the image creation process, 
a technique known as double buffering is used. The 
frame buffer memory is partitioned into two identi- 
cally sized areas, or buffers, commonly referred to 
as PING and PONG, and while the new animation 
frame is being created in one buffer, the current com- 
pleted frame is being displayed to the observer from 
the other. In the example of figure 3, bit planes 0 
through 3 constitute the PING buffer and bit planes 
8 through 11 constitute the PONG buffer. Only 
dynamic parts of the image are drawn to these bit 
planes. Static imagery that does not change on the 
screen is drawn to the static bit planes (4 through 7) 
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when the program is initialized and never changed. 
The software-controlled write mask is used to select 
the bit planes to be written into, and the software- 
controlled crossbar switches (XBS and CXBS) select 
the bit planes to be passed onto the LUVO’s for out- 
put to the video. The software alternately selects ei- 
ther PING or PONG to be combined with the static 
bit planes for output. The case shown in the figure 
will display the PONG buffer while the next dynamic 
frame imagery is being written to the PING buffer by 
the system processors. The 8-bit value coming out of 
the crossbar switches is applied to the input of the 
three LUVO’s and is a pointer to the same location in 
each of the color maps. Each color map in the LUVO 
is a 256-word 10-bit table of memory. As each pixel 
is addressed, the resulting pointer value output from 
the crossbar switches points to the same location in 
each LUVO and the values stored in each of these 
determine the amount of red, green, and blue that 
will be displayed at that pixel location. 

Animation Process 

Four steps must be carried out to create the new 
animation frame in either buffer: 

1. Erasure of the previous animation frame from the 
buffer 

2. Coordinate transformation of vectors, polygons, 
and character locations to create coordinate in- 
formation for the next frame 

3. Drawing the new animation frame vectors, poly- 
gons, and character strings into the newly erased 
buffer 

4. Displaying the new animation frame buffer to the 
observer 

These steps must be executed at maximum speed for 
a smoothly animated display. Speed is maximized 
by minimizing the number of instructions and by 
executing them in parallel whenever possible. Also, 
microcode may be created or revised to optimize 
speed. 

One more item must be considered in the image 
generation process. Step 4 of the display generation 
process described above is performed by the XBS 
and must be synchronized with the video sweep of 
the display monitor. This step determines what 
the observer sees and normally occurs during the 
vertical blanking interval of the video sweep. This 
synchronization is accomplished by using an IDL2 
instruction called WAITB, which simply delays the 
changeover of the XBS until the start of the vertical 
blanking interval. Since the changeover requires less 
time than the blanking interval, it will be invisible to 
the observer. Also since steps 1 through 3 are being 


applied to the nondisplayed buffer, there is no need 
to synchronize them. 

Erase Function 

Currently the erase function can be performed 
in two ways, and selection of the method can have 
an impact on update rate. The two methods are 
known as autoclear and selected area erase. The 
first method, autoclear, is a hardware function in 
the frame buffer controller (FBC). Two steps are 
required: (1) select the bit planes to be erased by 
setting an erase mask and (2) set a bit in one of 
the FBC control registers. Once these steps are 
completed, the bits of each pixel selected by the erase 
mask are erased as each pixel is selected for display 
by the video output circuitry of the FBC. Autoclear 
is normally set up right after the XBS is changed 
during the vertical blanking interval and is left on 
for two full video field periods. The main advantage 
of this method is that the BPS is free to do other 
things during the erase time. The main disadvantage 
is that it requires one complete video frame interval 
which is 32 msec in the high-resolution mode used in 
these displays. During the erase time no drawing 
may be safely done to the frame buffer memory. 
The second method, selected area erase, consists of 
drawing a filled rectangle in the background color 
over the entire area that needs to be erased. The 
upgraded version of the IDL2 rectangle fill command 
is capable of erasing the entire high-resolution screen 
in 28 msec. The main disadvantage of this method 
is that the BPS is tied up during the entire erase 
time. However, if the area to be erased is small 
relative to the entire screen, then selected area erase 
requires less time than autoclear. This can be an 
advantage even though the BPS is busy during the 
erase time. There is no straightforward method for 
determining which method is best, and the choice 
depends on the nature of the display and is best made 
by experimentation. 

Speed Improvements by Programming 
Techniques 

The display program was originally written us- 
ing sequential in-line code to implement steps 1 
through 4 described above. Autoclear was used for 
erasure, but nothing was done by the BPS during the 
32-msec erase time. This resulted in an animation 
update rate of 4 frames per second. Figure 4 shows 
the timing for this method. During the erase interval 
no new imagery may be drawn into the buffer. If im- 
agery were created at a screen location that had not 
yet been erased, it would disappear when the erase 
did occur. However, nondrawing functions such as 
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coordinate transformations, clipping, and perspec- 
tive projection may be performed during the erase 
interval The display program was therefore adjusted 
as illustrated in the timing diagram of figure 5. This 
change increased update rate from 4 to 8 frames per 
second. Further increase in update rate was pre- 
vented because of the slowness of the character gen- 
erator which ran on the BPS processor. Installation 
of the Advanced Graphics Generator (AGG4) was 
expected to increase the drawing speed of the char- 
acters, but did not. The remainder of this paper deals 
with the extensive analysis of this problem which led 
to significant revisions of the microcode associated 
with the character generation command. 

Speed Improvements by Microcode Revision 

The original microcode provided with the AGG4 
did not take full advantage of several advanced design 
features of the processor and the frame buffer display 
memory. These problems fell into three categories: 
(1) not taking advantage of the parallel processing 
capabilities of the AGG4 processor, (2) not taking 
advantage of the multiple pixel write capabilities of 
the GM-type FBM boards which were installed in 
the system, and (3) drawing characters of only one 
color and one size in each call of the command. 

The original character draw command (CHAR) 
for the AGG4-based system consisted of microcode 
files that ran on both the BPS and the AGG4. The 
BPS code passed screen coordinates and string infor- 
mation for each character string to the AGG4 and 
then started the AGG4 microcode which did the ac- 
tual character rendition. As originally designed, the 
BPS code passed the parameters for one string at a 
time to the AGG4 and then waited for it to complete 
its rendition before sending the parameters for the 
next string. This prevented any parallel operations. 
Also, the AGG4 microcode processed the characters 
one pixel at a time. While this did have the advan- 
tage of allowing rotation and magnification of char- 
acters, it did not take advantage of the multiple pixel 
write capabilities of the GM-type frame buffer mem- 
ory boards installed in the system, that is, being able 
to write 32 pixels at a time to the frame buffer mem- 
ory rather than only 1. Multiple pixel writes do not 
easily allow for rotation and magnification, but the 
speed increase far outweighs this loss of flexibility. 

The revised microcode for the two processors cor- 
rects the problems described in the previous para- 
graph and adds several other features. To achieve 
parallel processing and drawing different sized and 
color characters in a single call, the BPS microcode 
is now designed to pass to the AGG4 all the param- 
eters (coordinates and character string information) 
for all strings in a single call. These parameters are 


stored in the onboard font memory (OBFM) and up 
to 500 characters distributed over 100 strings may 
be handled with a single CHAR command. After 
the data transfer is complete, the BPS sends a com- 
mand to the AGG4 to start drawing. Then the BPS 
is free to do other things such as drawing vectors. 
After receiving the draw command from the BPS, 
the AGG4 proceeds to draw the characters. A sta- 
tus bit is set by the AGG4 so that the BPS does not 
attempt to start another CHAR command until the 
AGG4 is finished. Figure 6 shows the activity of the 
three processors when operating in this parallel mode 
when using the autoclear erase mode and figure 7 
shows it when using the selected area erase mode. 
Rotation and magnification of the characters are de- 
signed into the character font data, which also reside 
in the OBFM. To correct for this loss of the zoom 
and rotate capabilities, the character fonts are de- 
signed with a 90° rotation in the plane of the screen. 
This compensates for the monitor orientation in the 
cockpit. Different fonts are provided for the different 
character sizes. Also, some special symbols such as 
the track ball indicator in the attitude display indica- 
tor and the navigational symbols are implemented as 
special characters. Several other features built into 
the command include the capability to draw charac- 
ters of different sizes and colors in a single CHAR 
command and the ability to disable the erase func- 
tion of the AGG4 microcode. 

With the parallel processing capabilities of the 
revised microcode illustrated in figures 6 and 7, the 
limiting speed is determined by the processor that 
takes the longest to complete its tasks. If the BPS 
completes its work at time t 2 when the AGG4 is still 
busy, then the AGG4 sets the time limit. Then the 
time required to draw the vectors is essentially free 
because the BPS would otherwise be idle. If the time 
for the BPS to complete extends out to the 
situation is reversed and the BPS processing time 
determines the overall speed. 

High-Speed Character Generation 

Image Memory Mapping 

An understanding of image mapping in the frame 
buffer memory (FBM) is necessary to understand 
how characters are drawn. Figure 8 illustrates this 
mapping for the orientation of the monitor used in 
this project (turned 90° on its side). Each small rect- 
angle (referred to as an “FBM slice”) representing 
32 pixels in the vertical direction is mapped into one 
32-bit word of memory. Thirty-two of these FBM 
slices are required to define one raster line, which is 
1024 pixels high by 1 pixel wide, and these 32 FBM 
slices are mapped into 32 contiguous words of the 
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FBM. Moving vertically in figure 8 involves the com- 
bination of changing the bit number within a word 
and changing the word address in memory by a value 
denoted as n in the figure. Moving horizontally in- 
volves holding the bit number within the word con- 
stant and changing the word address by increments 
of 32 which is designated by k in the figure. 

The next step is to show how the pixel pattern 
representing a character is written into the FBM. 
This process for the letter “R” is illustrated in fig- 
ure 9. The character is represented by a series of ver- 
tical pixel patterns superimposed on the pixel array 
of the FBM. The vertical slices of the character are 
stored as bit patterns in a series of contiguous words 
in the onboard font memory (OBFM). In this case 
the character slices are 16 bits high so that 2 slices 
are stored in each 32-bit OBFM word and 5 OBFM 
words are required to store the 10 slices of the ex- 
ample character. Figure 9 illustrates the manner in 
which the 16-bit slices are stored in the 32-bit words. 
The five words of memory required for each character 
are known as a font entry and each slice of the char- 
acter is called a font slice. The collection of five-word 
entries for the entire character set is called the font 
table. The problem to be solved is how the AGG4 
hardware transfers the font slice entries to the FBM. 
Special hardware illustrated in figure 10 is required 
to accomplish this transfer, which is done 32 bits at 
a time. All the modules in figure 10 are located on 
the AGG4 circuit board. 

Positional Computations for the Character 

The font array for each character is transferred 
from the OBFM to the FBM one font slice at a 
time. The data flow follows the dashed arrows in 
figure 10. Figure 11 shows the condition of the font 
entry as it passes through each hardware component 
of the barrel shifter and of the inserter output register 
(IOR). The example shown is for the first font slice 
of the character “R” shown in figure 9 with the 
character positioned vertically four pixels, or bits, 
beyond a word boundary of the FBM memory slices. 
The processing steps are as follows: 

1. A font entry word (representing the first two font 
slices) is transferred from the OBFM to the 32-bit 
slice register. Note that the upper and lower 16 
bits in the slice register of figure 11 correspond to 
the odd and even font slices of figure 9. 

2. The first font slice located in the lower 16 bits of 
the slice register is rotated from lower to higher 
bit positions by up to 15 bit positions with the 
higher bits being wrapped around to the lower 
bit positions. The amount of rotation is deter- 
mined by how far the desired vertical position of 


the character differs from an integer multiple of 32 
(which is the vertical separation between FBM 
slices). The barrel shifter accomplishes this rota- 
tion operation in one microcode instruction time 
to save processing time. In the example, the rota- 
tion is four bits which will position the character 
with a four-pixel offset beyond an FBM slice word 
boundary. 

3. The rotated font entry (16 bits) is then written 
to the lower and the upper 16 bits of the IOR. 

4. There are now two copies of the rotated font 
entry. The choice of the bits to be output is 
controlled by the left and right mask values, 
which are in turn determined by the offset value. 
The location of the left mask is equal to the offset 
(in this case four bits). All bits numbered less 
than the position of the left mask are turned off. 
The position of the right mask is 16 bits greater 
than the left mask and all bits numbered greater 
than it are turned off. When the offset exceeds 
16 bits, the rotation is 

Rotation = Offset — 16 bits 

Also two FBM writes are necessary as shown in 
figure 12 (for an X offset of 20 pixels) to include 
the portion of the IOR output that spills over into 
the next FBM slice. The location of the left mask 
for the FBM write to slice n is still equal to the 
offset and the right mask is at bit 31. The left 
mask for the FBM write to slice (n + 1) is at bit 0 
and the location of the right mask is 

Right mask = Offset — 16 bits 

Note that the barrel shifter rotation is the same 
for the offset of 4 and 20 bits and that the 
appropriate contents of the IOR is selected by 
the setting of the left and right masks. 

Once the output for the first 16-bit font slice 
is complete, steps 1 through 4 are then repeated 
for the upper 16 bits of the contents of the slice 
register. Then this entire procedure is repeated 
for the remaining font slices in the character. For 
characters that are 32 pixels high, only one font slice 
is contained in each 32-bit font word in the OBFM. 
Since the barrel shifter can handle only 16 bits at a 
time, two passes through the procedures described 
above are necessary to process one font slice. Also, 
the spillover to the next FBM slice with its associated 
additional processing occurs whenever the offset is 
1 bit or greater. 

The special case of zero offset which occurs when 
the X coordinate is an integer multiple of 32 is worth 
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noting. In this case no rotation is necessary and the 
mask values are fixed at 

Left mask = 0 
Right mask =15 

for the 16-pixel font and 

Left mask = 0 
Right mask = 31 

for the 32-pixel font. The procedures described 
above reduce to simply writing the font slices out 
via the IOR. This requires less processing time and 
may be used advantageously to speed up character 
generation. 

Figure 13 shows the font bit manipulation for the 
whole character “R” for several offset values ranging 
from 0 to 24 pixels. 

Frame Buffer Memory Writes 

The results of the operations described in the pre- 
vious section are output from the inserter output reg- 
ister where either the font bit pattern or its comple- 
ment is available for output. This output may go 
to either the FBM for display or back to the OBFM 
to be available for further processing. The comple- 
mented form of the IOR output must be written to 
the FBM because of the manner in which the GM- 
type FBM boards work. In the FBM write, the pixel 
value as found in the IOR is not written directly to 
the FBM. Instead the contents of the IOR is written 
to the FBM mask register and the FBM mask register 
controls the write operation to the FBM according to 
the following rules: 

1. If the FBM mask register value is 1, then the pixel 
in the FBM is unchanged. 

2. If the FBM mask register value is 0, then the 
contents of the FBM shade register is written to 
the pixel. This shade register resides on the GM 
memory boards and is normally preloaded during 
program initialization. 

In order for a pixel bit to be turned on, two condi- 
tions must be met: (1) the bit must be a 1 in the 
shade register and (2) the corresponding bit of the 
write mask must be a 1. This write mask is also 
preloaded, normally at program initialization. Fig- 
ure 14 illustrates this point for 2 pixel locations of 
the 32 available from the IOR. The upper half of the 
figure shows the state of two adjacent pixels prior to 
a write from the IOR. The pixel value at location 0 
of the IOR is 1. Therefore, that pixel remains un- 
changed no matter what the shade and write mask 
values are set to and that pixel value in the lower 
portion of the figure is unchanged. The next pixel in 
the IOR is set to a value of 0. Now the shade value as 
modified by the write mask is written to the second 


pixel location at the bottom of the figure. This pro- 
cess is repeated for the remaining pixels of the FBM 
slice as shown by bits 2 through 31. The value in a 
particular bit location of the shade register is written 
to the FBM only if the corresponding write mask bit 
is 1. 

The data writing characteristics of the FBM 
boards described above mean that a character is 
not automatically erased by setting the appropriate 
bits to a value of 1 in the IOR output. Therefore, 
the erasure of characters requires a separate opera- 
tion. Specifically, all pixels that are on in a charac- 
ter and need to be turned off must be written with 
a shade value of 0 and all write mask bits turned 
on. The most time-consuming way of accomplish- 
ing this would be to redraw all characters with the 
shade value set to 0. A more efficient way, which 
works equally well, is to draw a rectangle at least as 
big as the character with the shade set to 0. This is 
accomplished by knowing the size and location of the 
character string to be erased and then drawing the 
rectangle. This erasure must be done for each ani- 
mation frame since it is possible that each and every 
character might change and/or move from frame to 
frame. As a result, it is necessary to know the loca- 
tion of each character string from frame to frame and 
this must be done separately for each buffer (PING 
or PONG). Figure 15 illustrates this. To relieve the 
applications program from this bookkeeping task, the 
microcode has been written to handle it. 

If the autoclear erase function is used, there 
is no need for the AGG4 to erase any individual 
strings. However, if the selected area erase mode 
is used, any strings outside of the selected area 
must be erased. The AGG4 microcode has been 
written to handle the erase function automatically 
and this erase function may be enabled or disabled 
for individual strings. The contents and location 
of the character strings for each buffer (PING and 
PONG) which are to be erased must be saved when 
they are drawn so that they are available for erasing 
prior to drawing the next animation frame. The 
data transfer is illustrated in figure 16. During 
the generation of each animation frame, the new 
string data for the current animation frame and the 
old string data for the previous frame in the same 
buffer are passed from the scratch pad memory to 
the OBFM. These data transfers are indicated by 
the solid arrows which terminate at the OBFM in 
figure 16. After the AGG4 is started, the BPS 
microcode transfers the current frame new string 
data to the old string data area in the scratch pad 
memory where it will be available for the next frame. 
This data transfer is indicated by the dashed arrow 
in figure 16 and relieves the applications program 
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from this bookkeeping task. For each succeeding 
animation frame the source of the old character string 
data for both of these transfers alternates between 
the PING and PONG storage areas in the figure. 

Limitations of the New Microcode 

The increase in character drawing speed has its 
price. The zoom and rotation capabilities of the orig- 
inal character command were lost. This minor prob- 
lem was corrected by creating font tables with the 
character size and rotation built in. Three differ- 
ent character sizes were needed: 10 by 14, 20 by 28, 
and 32 by 32 pixels. The 14 and 28 pixel dimensions 
were in the vertical direction so that each font slice 
threw away 2 or 4 bits, respectively. To have made 
use of these unused bits by data compaction would 
have added a significant processing burden on the 
microcode with its attendant increase in processing 
time. The task of building the font table was sim- 
plified by creating several font editor programs on a 
personal computer which had the character size and 
rotation built in. The output format of these pro- 
grams was identical to the data entry format required 
by the RDS 3000. Several special symbols were cre- 
ated in the 32- by 32-pixel character set. They were 
the filled track ball and the numbers 1 and 2 with cir- 
cles around them found in the airspeed meter at the 
upper left corner of the display (fig. 1). Also, several 
unused characters such as left and right parenthe- 
ses were used for the navigation aid symbols. Using 
characters for these symbols was faster than building 
them up from graphics primitives such as lines and 
circles. 

Character Draw Speed Measurements 

The time required to draw the different sized 
characters has been measured. The method used was 
to repeatedly draw a real-time frame containing a 
known number of characters. This program was run 
for 30 seconds and the time to draw a single character 
was computed as follows: 

T f = T tot /N . 

where 


Tj time per frame 

N number of frames 

Ttot measured time (normally 30 seconds) 

and the time required to draw one character is 

^ch = Tf/Ncfo 

where 

T c k time per character 

N c h number of characters per frame 

During this test, all synchronizing wait states 
were eliminated from the program to give a true time 
measurement. 

Table 1 shows the results of these timing mea- 
surements for the new microcode. Note that there is 
a time penalty when character strings are not posi- 
tioned vertically on 32 pixel boundaries. Also, there 
is a significant time penalty for the automatic erase 
function. If there are areas of the bit map image 
which are erased by use of the selected area erase 
function or if autoclear is used, then time may be 
saved by bypassing the character erase function. Ta- 
,ble 2 shows a comparison of character draw times 
between the new and original character commands. 
Note that vertical position on the screen has no effect 
on the speed of the original character command. 

Concluding Remarks 

The problem of slow animation update rates has 
been resolved for the primary flight display of the Ad- 
vanced Concepts Simulator at the Langley Research 
Center. The original update rate of 4 animation 
frames per second has been increased to 16 frames 
per second, which is as fast as the simulation pro- 
gram can currently run. This was accomplished by 
rewriting the character generator microcode to take 
better advantage of the hardware capabilities and by 
structuring the display program to take advantage 
of the parallel processing capabilities of the ADAGE 
RDS 3000 system. 

NASA Langley Research Center 
Hampton, VA 23665-5225 
February 6, 1989 
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Appendix 

Example of a Double-Buffered Display Program 

The program contained in this appendix is a double-buffered display (see fig. Al) utilizing all the 
techniques described in this paper. It is written in IDL2 and runs on the RDS 3000 utilizing the revised 
microcode. The update rate is 27 frames per second and the entire picture is drawn for each frame. 
The special symbols (filled circles and the circled 1 and 2) are single 32- by 32-pixel characters. The 
pattern-filled polygon is made up of eight 32- by 32-pixel characters (four for the boundary and four for 
the pattern fill). All characters change color: the special characters and the polygon change for each 
frame and the alphanumeric characters change once every 30 frames. The special characters and polygons 
move around inside the two boxes at the bottom of the display. The three wheels rotate like a set of 
meshed gears and the selected area erase is used to erase the region containing the wheels by drawing 
in the background color. The BPS transforms and renders the wheels while the AGG4 is drawing the 
characters (see fig. 7). The color changes cycle through a set of 16 colors with the boundary and pattern 
fill of the polygon cycling separately. 


THIS ISA DEMONSTRATION OF 
REAL TIME ANIMATED DISPLAY 
GENERATION ON THE 
ADAGE RDS 3000 

USING THE AGG4 COPROCESSOR FOR HIGH SPEED GENERATION 
OF CHARACTERS AND SPECIAL SYMBOLS 
THE ANIMATION UPDATE RATE IS 2 7 FRAMES PER SEC 
AND THE ENTIRE PICTURE IS REDRAWN FOR EACH FRAME 

THE CURRENT FRAME COUNT IS 0000 



Figure Al. AGG4 demonstration display. 
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APPENDIX 1 


THIS IS AN EXAMPLE DF A DOUBLE BUFFERED DISPALY UHICH 
UILL RUN ON THE ADAGE RDS 3000 USING THE MODIFIED MICROCODE 
UHICH IS DESCRIBED IN THIS PAPER. THE AGG4 PARALLEL PROCESSOR 
IS USED TO DRAU THE STANDARD AND SPECIAL CHARACTERS. THE SPECIAL 
CHARACTERS INCLUDE THE FILLED CIRCLE, THE CIRCLED NUMBERS 1 AND 2 
AND A CROSS HATCHED POLYGON. THE POLYGON BOUNDARY IS MADE UP 
OF 4 SPECIAL CHARACTERS AND THE INTERNAL CROSS HATCHING IS MADE 
UP OF 4 MORE. THE SPECIAL CHARACTER AND THE POLYGON MOVE AROUND 
INSIDE DF AND BOUNCE AGAINST THE SIDES OF TUO BOXES UHICH ARE DRAUN 
AT THE BOTTOM OF THE SCREEN. THE CHARACTER COMMAND IS EXECUTED AT 
THE BEGINNING OF EACH ANIMATION FRAME AND UHILE THE AGG4 IS 
RENDERING THE CHARACTERS, THE BPS AND MA1024 PROCESSORS ARE 
PERFORMING THE TRANSFORMATIONS FOR THE CHARACTER POSITIONS ON THE 
SCREEN AND THE TRANSFORMATION AND RENDITION OF THREE UHEELS UHICH 
ARE LOCATED AT THE UPPER RIGHT CORNER OF THE DISPLAY. THE BPS AND 
MAI 024 ARE PROCESSING IN PARALLEL UITH THE AGG4. ERASURE OF 
THE AREA CONTAINING THE THREE UHEELS IS ACCOMPLISHED BY DRAUING 
A FILLED RECTANGLE IN THE BACKGROUND COLOR. THE MICROCODE FOR 
THE RECTANGLE FILL COMMAND HAS BEEN ENHANCED TO RUN 50 TIMES 
FASTER THAN THE ORIGINAL. THE SPECIAL CHARACTERS CHANGE COLOR 
THROUGH A PRESCRIBED SEQUENCE OF COLORS FROM ONE ANIMATION FRAME 
TO THE NEXT. THE POLYGON BOUNDARY GOES THROUGH ONE SEQUENCE 
OF COLORS UHILE THE CROSS HATCHING GOES THROUGH A SECOND. 

THE STANDARD CHARACTERS UHICH ARE FIXED ON THE SCREEN CHANGE 
COLORS IN A SIMILAR SEQUENCE AFTER EVERY 30 ANIMATION FRAMES. 

THIS UAS DONE TO GET A SMOOTHER TRANSITION OF COLORS. 


; DEFINITIONS OF COMMONLY USED CONSTANTS. 

EQ = 1 . 

NE=2. 

LT = 3 . 

LE = 4 . 

GT =5 . 

GE=6 . 

AND = 7 . 

0R = 8 . 
xor=9. 

NAND=10 . 

NDR=1 1 . 

XN0R=12 . 

X3D=0 . 

X30P=1. 

X3DC=2 • 

X3D2=3 . 

X3DP2=4 . 

C0L0R=377 

DRAU=1000Q0 

RED= A X1 1 

GREEN=^X22 

BLUE=^X33 

YELL0U= A X44 

PINK=^X55 

UHITE=^X66 

BLACK=*X0Q 

E0L=4Q000 

CHXB=^0203\^02000 

DELTA=3 . 


DELTAM=-3 - 
LUV0=^0203\^00 
AMBER32= A X3333\^X3333 
PING=^XO\^XOOGF 
PONG=*XO\*XOQFO 

; DEFINE CHARACTER SIZE CODES 


5TD=2000 

WID=4000 

SPC=6000 

NDERASE=10000 


INIT #1 
RESDLU #1 


; ST ANDARD SIZE 10 X 14 
; DOUBLE SIZE 20 X 28 
; SPECIAL CHARACTERS 32 X 32 
; TAG FIELD BIT FOR NO ERASE OF CHARACTER 
; THIS IS NOT USED IN THIS EXAMPLE PROGRAM 
; DBF MEMORY 


MOVE #0, 100\10020 ; INITIALLY CLEAR AGG4 BUSY BIT 

MOVE #0, CHXB ; SET THE CHANNEL X BAR TO RED 

INITIALIZE THE X AND Y INCREMENT VALUES. THESE MILL INCREMENT 
THE POSITION OF THE MOVING SPECIAL CHARACTERS ON THE SCREEN 

MOVE #DELTA, DELX1 

MOVE #DELTAM\0,DELY1 

MOVE #DELT A , DELX2 

MOVE #DELTAM\ 0, DELY2 

MOVE #DELTA, DELX3 

MOVE #DELTAM\0,DELY3 

MOVE #DELTAM, DELX4 

MOVE #DELTAM\0,DELY4 

MOVE #DELTA,DELX5 

MOVE #DELTA\0, DELY5 

MOVE #DELTA, DELX6 

MOVE #DELTAM\0, OELYS 

MOVE #0ELTA,DELX7 

MOVE #DELTA\0 , DELY7 

MOVE #DELTA,DELX8 

MOVE #DELTAM\0,DELYB 

MOVE #DELTAM, DELX9 

MOVE #DELTAM\0,DELY9 

MOVE #DELTA, DELX10 

MOVE #DELTAM\0,DELY10 

MOVE #DELTA/ DELX11 

MOVE #DELTA\0, DEL Y1 1 

DRAU THE BOUNDARY BOXES FOR THE BOUNCING THINGS 

UMASK #0\400 ; WRITE MASK FOR STATIC BIT PLANE 

; WHICH CONTAINS THE BOUNCING THING 
; BOUNDARIES 

VECT VLBOUNCE ; DRAW THE BDX 


MOVE #PING/PINGPQNG jINITIALIZE PINGPONG TO #PING 


PING BUFFER IS BIT PLANES 0-3 
PONG BUFFER IS BIT PLANES 4-7 
STATIC BUFFER IS BIT PLANE 8 AND CONTAINS 
THE BOUNDARY BOX FOR THE BOUNCING THINGS 

LOAD THE SHADE TABLE WITH SOME COLORS IN THE FIRST 17 LOCATIONS 


10 



CMAPLD SHADE, #0, #77777X0, LUVO, #256. 


; LOCATION "LOOP" DENOTES THE START OF THE NEU ANIMATION FRAME 

; COMPUTATIONS 

LOOP: 

\ SET UP THE AGG4 TO DRAW ALL CHARACTERS AT THE BEGINNING OF 

; EACH FRAME 

JMPC DPONGCH, PINGPONG, #EQ, #PQNG 

• DRAU CHARACTERS IN PING BUFFER 

CHAR COORl-NEU, STRAD1_NEU,ATTAD1,0VLPING,0STRPING, PINGPONG 

\ FRDM HERE ON THE BPS IS PROCESSING VECTORS WHILE THE AGG4 IS 

; SIMULTANEOUSLY PROCESSING CHARACTERS 

i TRANSFORM THE VECTORS FOR THE ROTATING WHEELS 

SUB ROT 1+2/ #1777\0, ROT 1+2 

SUB R0T2+2/ #1777\0, R0T2+2 

ADD #1777\0,RDT3+2,R0T3+2 

COEFF #0,#0,#0,R0T1,TRAN1,SCALE1 

XFDRM VL1,VL2,#0,#X3D 

COEFF #1,#0,#0,R0T2,TRAN2,SCALE2 

XFDRM VL1, VL4,#1,#X3D 

COEFF #1,#0,#0,R0T3,TRAN3,SCALE3 

XFDRM VL1,VL6,#1,#X3D 


SENDERID 

#1 


UMASK 

#0X17 


FILREC 

RECLIST 

; ERASE THE REGION WHERE THE 
; WHEELS ARE DRAWN BY DRAWING 
; A RECTANGLE IN THE BACKGROUND 
; COLOR USING THE NEU HIGH SPEED 
j FILREC COMMAND 

VECT 

VL2 

; DRAW THE NEU VERSION OF THE WHEELS 

VECT 

VL4 


VECT 

VL6 


JMP 

LOOPC 



DPONGCH: 

; DRAU CHARACTERS IN PONG BUFFER 


CHAR COORl-NEU, STR AD 1-NEU/ ATT ADI , OVLPONG, OSTRPONG, P INGPONG 

TRANSFORM THE VECTORS FOR THE ROTATING WHEELS 

SUB RDT1+2/ #1777\0, R0T1+2 

SUB RDT2+2/#1777\0,R0T2+2 

ADD #1777\0,R0T3+2,R0T3+2 

COEFF #0/ #0/ #0/ R0T1, TRAN1, SCALE1 

XFORM VL1,VL2,#0,#X3D 

COEFF #1, #0/ #0, R0T2, TRAN2/ SCALE2 

XFORM VL1,VL4,#1,#X3D 

COEFF #l/#0,#0/R0T3/TRAN3/SCALE3 

XFORM VL1, VL6,#1,#X3D 
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SENDERID #1 

WMASK #0 \350 

FILREC RECLIST ; ERASE THE REGION WHERE THE 

; WHEELS ARE DRAWN BY DRAWING 
; A RECTANGLE IN THE BACKGROUND 
; COLOR USING THE NEW HIGH SPEED 
; FILREC COMMAND 

VECT VL2 ; DRAW THE NEW VERSION OF THE WHEELS 

VECT VL4 

VECT VLB 

LODPC : 


INCREMENT FRAME COUNTER DISPLAY 


ADD 

13, #1, 13 

# 

INCREMENT 

UNITS 

JMPC 

INCPL, 13, #LT, #10. 




MOVE 

#0, 13 




ADD 

12, #1, 12 

r 

INCREMENT 

TENS 

JMPC 

INCPL, 12, #LT, #10. 




MOVE 

#0, 12 




ADD 

11, #1,11 

i 

INCREMENT 

HUNDREDS 

JMPC 

INCPL, 11, #LT, #10. 





RESET ALL DIGITS TO ZERO IF LAST COUNT WAS 9S9 


MOVE 

MOVE 

MOVE 

INCPL : GTABLE 

SHIFT 
GTABLE 
SHIFT 
GTABLE 
SHIFT 


#0, 13 
# 0 , 12 
# 0,11 

GS1, DIGIT, II 
G51 , #8 . , GS1 
GS2, DIGIT, 12 
GS2 , # IS . , GS2 
GS3, DIGIT, 13 
GS3, #24 . , GS3 


UPDATE THE STRING FOR THE FRAME COUNTER 

MOVE #40, STR22 

OR GS1, STR22,STR22 

OR GS2, STR22,STR22 

OR GS3,STR22,STR22 


FRAME COUNTER UPDATE COMPLETE 
UPDATE THE NEW BUFFER 


UPDATE MID SIZE AND STANDARD SIZE CHAR COLORS 


SOME OF THE STRINGS MOVE AND CHANGE COLORS AT THE SAME TIME 
THEY WILL BE UPDATED FIRST START THE CHANGES FOR THESE 
STRINGS BY UPDATING C00R1 THROUGH C00R1B 

SET THE MAXIMUM AND MINIMUM VALUES FOR THE BOUNCING BALLS 

MOVE #500. , XMIN 

MOVE #890 . , XMAX 
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MOVE #535 . \0, YMIN 
MOVE #925 . \0, YMAX 

NDU DO THE INCREMENTS AND COLOR CHANGES TO THESE STRINGS 

MOVE #COQRl , REG1 
MOVE #DELX1 , REG2 
MOVE #DELY1 , REG3 
JMPSUB CHANGE 
MOVE #CQ0R2, REG1 
MOVE #DELX2, REG2 
MOVE #DELY2, REG3 
JMPSUB CHANGE 
MOVE #C00R3, REG1 
MOVE #DELX3, REG2 
MOVE #DELY3/ REG3 
JMPSUB CHANGE 
MOVE #C00R4, REG1 
MOVE #DELX4, REG2 
MOVE #DELY4, REG3 
JMPSUB CHANGE 
MOVE #C00R5, REG1 
MOVE #DELX5,REG2 
MOVE #DELY5/ REG3 
JMPSUB CHANGE 

SET THE MAXIMUM AND MINIMUM VALUES FOR THE BOUNCING SPECIAL 
CHARACTERS "CIRCLED 1 AND CIRCLED 2" 

MOVE #500 . , XMIN 
MOVE #903 . / XMAX 
MOVE #522 . \0, YMIN 
MOVE #925 • SO/ YMAX 

MOVE #C00R6, REG1 
MOVE #DELXB / REG2 
MOVE #DELY6, REG3 
JMPSUB CHANGE 
MOVE #C00R7,REG1 
MOVE #DELX7,REG2 
MOVE #DELY7 / REG3 
JMPSUB CHANGE 
MOVE #C00R8/ REG1 
MOVE #DELX8/ REG2 
MOVE #DELYB, REG3 
JMPSUB CHANGE 
MOVE #C00R9, REG1 
MOVE #DELX9/ REG2 
MOVE #DELY9,REG3 
JMPSUB CHANGE 
MOVE #C00R10/ REG1 
MOVE #DELX10, REG2 
MOVE #DELY10, REG3 
JMPSUB CHANGE 


NOU CHANGE THOSE STATIONARY STRINGS UHICH ONLY CHANGE COLOR 
AND ONLY DO IT AFTER EVERY 30 FRAMES HAVE BEEN DRAUN 

ADD #1 / FCT , FCT 

JMPC NOCOLUPD, FCT, #NE, #30 . 
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MOVE 

#0/ FCT 

MOVE 

#CQ0RL1,REG1 

JMPSUB 

CHGCOL 

MOVE 

#C00RL2, REG1 

JMPSUB 

CHGCOL 

MOVE 

#C00RL3, REG1 

JMPSUB 

CHGCOL 

MOVE 

#C00RL4, REG1 

JMPSUB 

CHGCOL 

MOVE 

#CQ0RL5/ REG1 

JMPSUB 

CHGCOL 

MOVE 

#C00RL6, REG1 

JMPSUB 

CHGCOL 

MOVE 

#C00RL7/ REG1 

JMPSUB 

CHGCOL 

MOVE 

#C00RL8, REG1 

JMPSUB 

CHGCOL 

MOVE 

#C00RL9, REG1 

JMPSUB 

CHGCOL 

MOVE 

#C00RL10y REG1 

JMPSUB 

CHGCOL 

MOVE 

#C00RL 1 1 / REG1 

JMPSUB 

CHGCOL 

MOVE 

#CD0RL12,REG1 

JMPSUB 

CHGCOL 


NOCOLUPD : 


UPDATE THE COLOR AND COORDINATES 

DF THE SPECIAL CHARACTERS WHICH MAKE UP THE 

POLYGON THIS IS DONE EVERY FRAME 


SET THE MAXIMUM AND MINIMUM VALUES FOR THE POLYGON FILL AND 
POLYGON BOUNDARY 

MOVE #500 • / XMIN 
MOVE #865 . / XMAX 
MOVE #60 . \0, YMI N 
MOVE #500 . \0, YMAX 

NOU UPDATE IT 

MOVE #C00RU / REG1 
MOVE #DELX1 1 , REG2 
MOVE #DELY11,REG3 
JMPSUB CHANGE 
MOVE #C00R15 / REG! 

JMPSUB CHGCOL 
MOVE C00R11+1 / C00R12+1 
MOVE C0DR11+1, C00R13+1 
MOVE C0QR11+1, C00R14+1 
MOVE C00R15+1, C00R16+1 
MOVE CD0R15+1/C00R17+1 
MOVE C00R15+1/C00R18+1 


UPDATE THE COORD OF THE SPECIAL SYMBOLS WHICH MAKE UP 

CROSS HATCHED POLYGON BY ADDING OR SUBTRACTING THE APPROPRIATE 

CONSTANTS TO C00R11 X AND Y COMP 

ADD C00R1 1 , #-32. \0 ■ , CQ0R12 


; CHANGE COLOR AND COORDINATE 
; CHANGE ONLY THE COLOR 
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ADD C0QR1 1 , #0 . \32 . , C0QR13 

ADD COORU, #-32.\32.,C00R14 

; DUPLICATE THE COORDINATES OF THE POLYGON CROSSHATCH FILL 

; BY COPYING THE CORRESPONDING COORDINATES OF THE SPECIAL 

; CHARACTERS UHICH MAKE UP THE POLYGON BOUNDARY 

MOVE C0DR1 1 , C00R15 

MOVE C00R1 2/ CQ0R1S 

MOVE C00R13, C00R17 

MOVE C00R14, C00R18 

9 

; CHANGE THE CROSSBAR SUITCH 

LOOP 1 : JMPC DPONG, PINGPONG, #EQ, #PONG 


ADD 

#0\1, COUNT, COUNT 




MDVE 

#PONG, PINGPONG 




UAITB 





BLKMOVE 

PINGTB, 302\0,#34. 

; SET 

XBAR 

TO DISPLAY PING 

JMP 

LOOP 

; GO 

BACK 

TO " LOOP “ TD START 



; THE 

NEXT 

ANIMATION FRAME 

DPONG : 





ADD 

#1, COUNT, COUNT 




MOVE 

#PING, PINGPONG 




UAITB 





BLKMOVE 

PONGTB, 302\0, #34. 

; SET 

XBAR 

TO DISPLAY PONG 

JMP 

LOOP 

; GO 

BACK 

TO “LOOP" TO START 



; THE 

NEXT 

ANIMATION FRAME 


; THIS SUBROUTINE INCREMENTS COORDINATES AND CHANGES COLOR 

CHANGE: 

; THIS IS THE ENTRY POINT TO CHANGE COORDINATES AND COLORS BOTH 

; FIRST INCREMENT THE COORDINATE AS POINTED TO BY REG1 

9 

MOVE BREG2, DELX 

MOVE 6REG3, DELY 

AND 8REG1,#0\177777, TEMPI ;TEMP1 HAS THE X COORD 

AND BREG1,#177777\0,TEMP2 ;TEMP1 HAS THE Y COORD 


INCREMENT THE COORDINATES 


JMPC 

MOVE 

JMP 

PX1 : JMPC 

MDVE 

PY1: JMPC 

MOVE 
JMP 

PY2: JMPC 

MOVE 

PFIN1: ADD 

ADD 


PX1, TEMPI , #LT, XMAX 

#DELTAM, DELX 

PY1 

PY1, TEMPI, #GT,XMIN 
#DELTA, DELX 
PY2,TEMP2,#LT, YMAX 
#DELTAM\0, DELY 
PFIN1 

PFIN1, TEMP2, #GT, YMIN 
#DELTA\0, DELY 

DELX, TEMPI, TEMPI 

DELY, TEMP2,TEMP2 


; TEST FOR MAXIMUM X 


; TEST FOR MINIMUM X 
; TEST FOR MAXIMUM Y 


; TEST FOR MINIMUM Y 


INCREMENT COMPLETE 

OR TEMPI, TEMP2,BREG1 

MOVE DELX, BREG2 

MOVE DELY, BREG3 


INCREMENT REG1 TO POINT TO THE SHADE LOCATION 


CHGCOL : 


THIS IS THE ENTRY POINT TO ONLY CHANGE COLOR 


ADD #1 , REG1 , REG1 


NOU INCREMENT THE COLOR AS POINTED TO BY REG1 



AND 

0REG1,#17\O, TEMPI 


AND 

8REG1 , #360X0, TEMP2 


ADD 

TEMPI, #1X0, TEMPI 


AND 

TEMP1,#17\0, TEMPI 


JMPC 

COLA, TEMPI, #NE,#0 


MOVE 

#1X0, TEMPI 

COLA: 

ADD 

TEMP2,#20\0, TEMP2 


AND 

TEMP2, #360X0, TEMP2 


JMPC 

COLB, TEMP2, #NE, #0 

COLB: 

MOVE 

#20X0, TEMP2 


OR 

TEMPI, TEMP2,TEMP3 


AND 

@REG1, #177400X0, 8REG1 


OR 

RETURN 

TEMP3,@REG1,@REG1 


; ISOLATE PING COLOR 
; ISOLATE PDNG COLOR 


.SETORG ^0202X^07000 


; THIS IS THE COORDINATE LIST FOR THE NEU ANIMATION FRAME CHARACTER BUFFER 
2 

C00R1-NEU: 

2 

i NEU COORDINATES FOR BOUNCING BALLS AND CIRCLED 1 AND 2 


» 

C00R1: 

.WORD 

900. X816. 


. UQRD 

( RED 1 SPC ) \0 

C00R2: 

. UORD 

B50.X620. 


. UORO 

( GREEN 1 SPO \0 

C0QR3: 

.UORD 

800.X652. 


.UORD 

( BLUE 1 SPC ) \0 

C00R4: 

.UORD 

750.X684. 


.UORD 

( YELLOUISPOXO 

C0QR5 : 

.UORD 

700.X716. 


.UORD 

( PINK 1 SPC ) \0 

CQ0R6 : 

.UORD 

650.X748. 


.UORD 

(UHITEISPOXO 

C00R7 : 

.UORD 

600.X812. 


.UORD 

( PINK 1 SPC ) \0 

COORB: 

.UORD 

550.X820. 


.UORD 

(YELLOUISPOXO 

C0DR9 : 

.UORD 

800. X82B. 


.UORD 

(YELLOUISPOXO 

C00R10: 

.UORD 

700.X827. 


.UORD 

( GREEN 1 SPC) XO 


; NEU COORDINATES FOR CROSS HATCHED POLYGON 

/ 

C00R11: . WORD 232.NB00. 
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. UORD 

( GREEN 1 SPC ) \0 

COOR12: 

• UORD 

200. \BOO. 


.UORD 

( GREEN 1 SPC ) \0 

C00R13 : 

.UORD 

232.X832. 


.UORD 

( GREEN 1 SPC ) \0 

CQQR14 : 

.UORD 

200 . \832 . 


.UORD 

(GREENISPC)NO 

C00R15 : 

.UORD 

232 . \800 . 


.UORD 

( UHITE 1 SPC ) \0 

COORlBs 

.UORD 

200 . \800 . 


.UORD 

( UHITE 1 SPC ) \0 

C00R17 : 

.UORD 

232.X832. 


.UORD 

( UHITE 1 SPC ) \0 

COORIB: 

.UORD 

200 . \832 . 


.UORD 

t UHITE 1 SPC ) \0 


NEU COORDINATES FOR THE UIDE CHARACTERS 


COORLls 

.UORD 

1000. \32. 


.UORD 

1 RED 1 UID ) \0 

C00RL2: 

.UORD 

B40 . \32 . 


.UORD 

( UHITE 1 UID ) \0 

C0QRL3 s 

.UORD 

500. \32. 


.UORD 

t YELL0UIUID)\0 

CD0RL4 s 

.UORD 

1000. \64. 


.UORD 

I UHITE 1 UID ) \0 

CD0RL5 : 

.UORD 

1000. \9B. 


.UORD 

( BLUE 1 UID ) \0 

COORLS: 

.UORD 

1000. \128. 


.UORD 

( RED 1 UID ) \0 


NEU COORDINATES FDR THE FRAME COUNTER AND ITS HEADER 


» 

C00RL7 : 

.UORD 

1000. \340. 



.UORD 

( BLUE 1 STD ) \Q 


CD0RL8 : 

.UORD 

650. \340. 

; LOCATION DF COUNTER 


-UORD 

( RED 1 UID ) \0 



NEU COORDINATES FOR STD CHARS 


l 

C00RL9: 

.UORD 

1000. \160. 


.UORD 

( UH I TE I STD ) \ 0 

C00RL10: 

.UORD 

900 . \ 192 . 


.UORD 

( GREEN 1 STD ) \0 

C00RL11 : 

.UORD 

1000. \224. 


.UORD 

( YELLOU 1 STD ) \0 

C0DRL12 : 

.UORD 

1000. \256. 


.UORD 

t RED 1 STD 1 EOL ) \0 


THIS IS THE OLD COORDINATE LIST FOR ERASING THE CHARACTERS 
; IN THE PING BUFFER FOR THE PREVIOUS ANIMATION FRAME 

; IT IS INITIALLY THE SAME AS THE NEU BUFFER 

; OLD PING BUFFER COORDINATES FOR BOUNCING BALLS 

; AND CIRCLED 1 AND 2 

OVLPINGs 


.UORD 

900. \816. 

.UORD 

( RED 1 SPC ) \Q 

.UORD 

850 . \620 . 

.UORD 

C GREEN 1 SPC ) \0 


- UORD BOO . N652 . 

.WORD £ BLUE J SPC ) NO 
. UORO 750 . N684 . 

. UDRD ( YELLOWISPONO 
. WORD 700 . N71S . 

. UORO £ P INK I SPC ) NO 
. UDRD 650.N748. 

.UDRD ( UHITE I SPC ) NO 
.WORD 600 . N91 2 . 

.UORO ( P INK I SPC ) NO 
.WORD 550.N920. 

. UORO ( YELLOU I SPC ) NO 

- WORD 500.N928. 

.UDRD ( BLUE I SPC 3 NO 

. UORO 450.N927. 

.UDRD ( GREEN 1 SPC ) NO 

OLD PING BUFFER COORDINATES FOR CROSS HATCHED POLYGON 

. UORO 232.NS00. 

.UDRD ( GREEN I SPC ) NO 
.UDRD 200.N800. 

. UORO £ GREEN I SPC ) NO 
.UORO 232.NB32. 

. UORD £ GREEN i SPC ) NO 
•UDRD 200.NB32. 

.UORD £ GREEN I SPC ) NO 
.UORD 232.NB00. 

.UORD £ UHITE I SPC ) NO 
.UORD 200.N800. 

.UORD ( UHITE I SPC ) NO 
.UORD 232.NS32. 

.UORD £ UHITE I SPC ) NO 
.UORD 200.N832. 

.UORD (UHITE I SPC ) NO 

OLD PING BUFFER COORDINATES FOR THE UIDE CHARACTERS 

.UORD 1000. N32. 

.UORD £ RED I UID ) NO 
.UORD 840. N32. 

.UORD (UHITEIUID)NO 
.UORD 500. N32. 

.UORD £ YELLOU 1 UID ) N 0 
.UORD 1000. N64. 

.UORD (UHITEIUID)NO 
.UORD 1000. N96. 

.UORD £ BLUE I UID ) NO 
.UDRD 1000. N12B. 

.UORD ( RED I UID ) NO 

OLD PING BUFFER COORDINATES FOR LAST TUO ROUS OF LARGE CHARACTERS 

.UORD 1000. N2B8. 

.UORD £ BLUE J STD ) NO 

.UORD 800.N340. ;LOCATION OF COUNTER 

.UORD ( RED I UI D ) NO 

OLD PING BUFFER COORDINATES FOR STD CHARS 
.UORD 1000. N160. 
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.WORD ( UHITE I STD ) \0 
. UDRD 900 . \ 192 . 

- UORD ( GREEN I STD ) \0 
-UDRD 1000. N224. 

.UDRD ( YELLDU I STD ) \0 
-UDRD 1000. \25E. 

.UDRD ( RED I STD I EOL ) \0 

THIS IS THE OLD COORDINATE LIST FOR ERASING THE CHARACTERS 
IN THE PONG BUFFER FDR THE PREVIOUS ANIMATION FRAME 
IT IS INITIALLY THE SAME AS THE NEU BUFFER 


; OLD PONG BUFFER COORDINATES FOR BOUNCING BALLS AND 

; CIRCLED 1 AND 2 

OVLPONG : 


-UORD 

900. \81B. 

-UDRD 

( RED 1 SPC ) NO 

-UORD 

B50 . \B20 . 

.UORD 

( GREEN 1 SPC ) \0 

.UORD 

800 . NB52 . 

-UORD 

C BLUE 1 SPC ) \0 

.UORD 

750 . NB84 . 

.UORD 

( YELLOUISPONO 

-UORD 

700 . \71B . 

.UORD 

( PINK 1 SPC ) NO 

.UORD 

B50.N74S. 

-UORD 

(UHITEISPC)NO 

.UORD 

BOO . \912 . 

.UORD 

(PINKISPC)NO 

-UORD 

550. \920. 

-UORD 

( YELLOU 1 SPC ) \0 

.UORD 

500 . \92B . 

.UORD 

( BLUE i SPC ) \0 

.UORD 

450 . \927 - 

.UORD 

( GREEN 1 SPC ) \0 


OLD PONG BUFFER COORDINATES FOR CROSS HATCHED POLYGON 


.UDRD 

232. \800. 

.UORD 

( GREEN 1 SPC ) NO 

.UORD 

200 . \800 . 

.UORD 

( GREEN 1 SP C ) N 0 

.UORD 

232.N832. 

.UORD 

(GREENISPC)NO 

-UORD 

200 . \832 . 

.UDRD 

( GREEN 1 SPC ) \0 

.UDRD 

232 . \B00 - 

.UORD 

t UHITE 1 SPC ) NO 

-UDRD 

200 . \800 . 

.UORD 

( UHITE 1 SPC ) \0 

.UORD 

232.NB32. 

-UDRD 

( UHITE 1 SPC ) \0 

.UORD 

200. \B32. 

.UDRD 

( UHITE 1 SPC ) NO 


OLD PONG BUFFER COORDINATES FOR THE UIDE CHARACTERS 


UDRD 

1000. \32. 

UDRD 

( RED 1 UID 5 NO 

UDRD 

840. \32. 

UORD 

( UHITE 1 UID ) NO 



. WORD 500. \32. 

. WORD ( YELLOU I UID ) \0 
.WORD 1000. \64. 

. UORD ( WHITE I UID ) \0 
.WORD 1000. \96. 

.UORD ( BLUE I UID ) \0 
.UORD 1000. \128. 

.UORD ( RED I UID ) \0 

w 

; OLD PONG BUFFER COORDINATES FOR LAST TUO ROUS OF LARGE CHARACTERS 

* 

.UORD 1000. \288. 

.UORD ( BLUE I STD ) \0 

.UORD BOO . \340 . ;LOCATION OF COUNTER 

.UORD ( RED I UID ) \0 

; OLD PONG BUFFER COORDINATES FOR STD CHARS 

9 

.UORD 1000. \160. 

.UORD ( UH ITE I STD ) \0 
.UORD 900.U92. 

.UORD ( GREEN I STD ) \0 
.UORD 1000. \224. 

.UORD ( YELLOU I STD ) \Q 
.UORD 1000. \256. 

.UORD ( RED I STD I EOL ) NO 

; STRING POINTERS FOR THE SPECIAL SYMBOLS AND POLYGON 

9 

STRAD1 _NEU : 

STRAD2 : .UORD STR10, STR10, STR10,STR10, STR10 

.UORD STR11, STR11,STR11,STR12,STR12 
STRAD3 : .UORD STR1 3, STR14, STR15, STR16, STR17, STR18, STR19, STR20 

; STRING POINTER FOR FIRST 3 ROUS OF LARGE CHARACTERS 

STADL1 : .UORD STR1, STR2, STR3, STR4, STR5 / STR6,STR2i,STR22 

; STRING POINTER FOR THE FOUR ROUS OF STANDARD SIZE CHARACTERS 

STADL2 : .UORD STR7, STR8, STR9 , STRA 

; STRING POINTERS FOR OLD STRINGS PING BUFFER 


; THIS IS THE OLD STRING POINTER LIST FOR ERASING THE CHARACTERS 

; IN THE PING BUFFER FOR THE PREVIOUS ANIMATION FRAME 

; IT IS INITIALLY THE SAME AS THE NEU BUFFER 

OSTRPING: 

.UORD STR 10 / STR10 , STR10, STR10, STR10 

.UORD STR11, STR11, STR1 1 , STR12, STR12 

.UORD STR13, STR14, STR15, STR16, STR17, STR 18, STR19, STR20 
STRING POINTER FOR FIRST 3 ROUS OF LARGE CHARACTERS 
. UORD STR1 / STR2,STR3 / STR4, STR5, STRB, STR21 , STR22 
STRING POINTER FOR THE FOUR ROUS OF STANDARD SIZE CHARACTERS 
.UORD STR7, STRS, STR9, STRA 
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THIS IS THE OLD STRING POINTER LIST FOR ERASING THE CHARACTERS 
IN THE PONG BUFFER FOR THE PREVIOUS ANIMATION FRAME 
IT IS INITIALLY THE SAME AS THE NEU BUFFER 


OSTRPONG : 

. UORD STRIO, STRIO, STRIO, STRIO, STRIO 
. UORD STR11, STR11, STR11, STR12, STR12 

. UORD STR13,STR14,STR15,STR16,STR17,STR18,STR19,STR20 
7 

; STRING POINTER FOR FIRST 3 ROUS OF LARGE CHARACTERS 

9 

. UORD STR1 , STR2, STR3, STR4, STR5, STR6, STR21 , STR22 

9 

; STRING POINTER FOR THE FOUR ROUS OF STANDARD SIZE CHARACTERS 

/ 

.UORD STR7, STR8, STR9,STRA 


STRINGS FOR SPECIAL SYMBOLS THIS IS THE SAME FOR BOTH BUFFERS 


STRIO: 

• BYTE 

' A ' , 0 


STRii: 

• BYTE 

'B',0 


STR12 : 

• BYTE 

'C',0 


7 

0 

» 

STRINGS 

FOR CROSS HATCHED POLYGON 


7 

STR13 : 

• BYTE 

'D', 0 


STR14 : 

• BYTE 

'E',0 


STR15 : 

• BYTE 

'F',0 


STR1S : 

• BYTE 

'G',0 


STR17 : 

■ BYTE 

o 

X 


STR1B : 

• BYTE 

'I', 0 


STR19 : 

• BYTE 

'J',0 


STR20: 

• BYTE 

'K',0 


7 

7 

STRINGS 

FOR FIRST 3 ROUS OF LARGE CHARACTERS 


7 

STR1 : 

• BYTE 

'THIS IS ',0 


STR2 : 

• BYTE 

'A DEMONSTRATION ',0 


STR3 : 

• BYTE 

'OF', 0 


STR4 : 

• BYTE 

'REAL TIME ANIMATED DISPLAY', 0 


STR5 : 

• BYTE 

' GENERATION ON THE ',0 


STR6 : 

• BYTE 

' ADAGE RDS 3000 ',0 


7 

• 

STRINGS 

FOR THE FOUR ROUS OF STANDARD SIZE CHARACTERS 

# 

STR7 : 

.BYTE 

'USING THE AGG4 COPROCESSOR FOR HIGH SPEED 

GENERATION 

STR8 : 

.BYTE 

'OF CHARACTERS AND SPECIAL SYMBOLS ',0 


STR9 : 

.BYTE 

'THE ANIMATION UPDATE RATE IS 22 FRAMES PER 

SEC',0 

STRA: 

.BYTE 

'AND THE ENTIRE PICTURE IS REDRAUN FOR EACH 

FRAME', 0 

« 

7 

STRINGS 

FOR THE LAST TUO ROUS OF LARGE CHARACTERS 


7 

STR21 : 

.BYTE 

'THE CURRENT FRAME COUNT IS',0 


STR22 : 

.BYTE 

'0000', 0 


7 

7 

CROSSBAR 

SETTINGS FOR PING BUFFER 



PINGTBs .WORD 

• UORD 

• UORD 


0,1,2,3,10,77,77,77 
77, 77,77,77,77,77,77,77 
77,77,77,77,77,77,77 ,77 
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» 

PQNGTBs 


DIGIT; 


us x ; 

GS2: 

GS3 : 

GS4 ; 

II: 

12: 

13: 

14: 

IC: 

INCT: 
ZERO: 
TEMPI: 
TEMP2 : 
TEMP3 : 
FCT : 

ICT: 

PINGPDNG 
DELX : 
DELY: 
DELX1 : 
DELY1: 
DELX2 : 
DELY2 : 
DELX3 : 
DELY3 : 
DELX4 : 
DELY4: 
DELX5 : 
DELY5 : 
DELX6 : 
DELY6 : 
DELX7: 
DEL Y7 : 
DELX8 : 
DELY8 : 
DELX9 : 
DEL Y9 : 
DELXIO : 


-WORD 

77, 77 , 77 , 77 , 77 , 77 , 77,77 

. UORD 

77 , 77 

CRDSSBAR SETTINGS FDR PONG BUFFER 

.UORD 

4,5,6,7,10,77,77,77 

.WORD 

77 , 77 , 77 , 77 , 77 , 77 , 77 ,77 

. WORD 

77 , 77 , 77 , 77 , 77 , 7 7 , 77,77 

.WORD 

77,77,77,77,77,77,77,77 

.WORD 

77, 77 

STORAGE 

FOR FRAME COUNTER DIGITS 

.BYTE 

'O', 0, 0, 0 

-BYTE 

> 

V 

o 

o 

o 

■ BYTE 

'2', 0,0,0 

.BYTE 

'3', 0,0,0 

.BYTE 

'4', 0,0,0 

.BYTE 

'5', 0,0,0 

.BYTE 

'6', 0, 0, 0 

.BYTE 

'7', 0,0,0 

-BYTE 

'8', 0,0,0 

.BYTE 

'9', 0,0,0 

.UQRD 

0\Q 

.WORD 

0\0 

. UQRD 

0\0 

.UQRD 

0\0 

. UQRD 

0\0 

.UQRD 

0\0 

. UORD 

0\0 

.UQRD 

0\0 

.UQRD 

0\0 

.UQRD 

0\0 

.UORD 

0\0 

.UQRD 

0\0 

.UQRD 

0\0 

.UQRD 

0\0 

.UORD 

0\0 

.UORD 

0\0 

; 

.UQRD 0\0 

.UQRD 

oso 

.UORD 

0\0 

.UORD 

0\0 

.UQRD 

0\0 

.UQRD 

0\0 

.UQRD 

0\0 

.UORD 

0\0 

.UORD 

0\0 

.UORD 

0\0 

.UORD 

0\0 

.UQRD 

0\0 

.UORD 

0\0 

.UQRD 

0\0 

.UORD 

0\0 

.UORD 

0\0 

.UQRD 

0\0 

.UORD 

0\0 

.UORD 

0\0 

.UQRD 

0\0 

.UQRD 

0\0 

.UORD 

0\0 


i 
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\ 


DELYlOs 

.UORD 

ONO 

DELX11 : 

.UORD 

ONO 

DELY11: 

.UORD 

ONO 

DEL: 


.UORD 

ONO 

DEL2: 


.UORD 

ONO 

DEL3 


.UORD 

ONO 

DEL4 


.UORD 

ONO 

DEL5 


.UORD 

ONO 

DELS 


.UORD 

ONO 

DEL7 


.UORD 

ONO 

0EL8 


.UORD 

ONO 

0EL9 


.UORD 

ONO 

DEL1C 

) : 

.UORD 

ONO 

TEST 1 

L: 

.UORD 

ONO 

TST1 ; 


.UORD 

ONO 

XMIN ! 


.UORD 

ONO 

XMAX: 


.UORD 

ONO 

YMIN: 


.UORD 

ONO 

YMAXi 


.UORD 

ONO 


; TABLES OF ROTATION, TRANSLATION AND SCALING FOR THE 

; TRANSFORMATIONS 

ROT 1 : -WORD 0\0 

. UDRD 0\0 
. UORD 0\0 

TRAN1 : .UORD 0\105. 

-UORD OUOO. 

.UORD 0\0 

SCALE 1 : .UORD 0 X77777 

.UORD ON 77777 

.UORD 0X77777 

R0T2 : .UORD 0\0 

.UORD ONO 
.UORD ONO 

TRAN2: .UORD 0N387. 

.UORD ON 100 . 

.UORD ONO 

SCALE2: .UORD 0N77777 

.UORD ON 77777 

.UORD ON 77777 

RQT3 : .UORD ONO 

.UORD ONO 
.UORD ONO 

TRAN3 : .UORD 0X246. 

.UORD 0N241 . 

.UORD ONO 

SCALE3: .UORD 0X77777 

.UORD 0X77777 

.UORD 0N77777 

VECTORS LIST FOR THE CONTAINING BOXES 

VLBQUNCE : 

.UORD 500.N500. 

.UORD ONO 
.UORD 500.X925. 

.UORD (DRAUIRED)XO 
.UORD 925.XS25. 

.UORD ( DR AU I RED ) NO 
.UORD 925.N500. 
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VL1 : 


.WORD £ DRAU I RED ) \0 
. UDRD 500 . \50G . 

- WORD ( DRAU l RED ) \0 
. UORD 0 . \500 . 

.UDRD 0\0 
.UORD 0 . \925 . 

.UORD £ DRAU I RED ) \0 
.UORD 500 . \925 . 

.UORD £ DRAU I RED ) \0 
.UDRD 500 . \50Q . 

.UDRD ( DRAU I RED ) \0 
.UDRD 0 . \500 . 

.UDRD ( EOL I DRAU I RED ) \0 

VECTOR DEFINITIONS FOR THE ROTATING UHEELS 

.UORD 0\100. 

.UDRD 0\0 
.UDRD 17 . \98 . 

.UORD £ DRAU I GREEN ) \ 0 
.UORD 0\0 
.UDRD £ DRAU I RED ) \0 
.UDRD 34.X94. 

.UDRD ( DRAU 1 UHITE ) \0 
.UORD 50.\S7. 

.UDRD £ DRAU I PINK) \0 
.UDRD 0\0 

.UDRD £ DRAU I YELLOU) \0 
.UORD £4 . \ 77 . 

.UDRD £ DRAU I BLUE ) \0 
.UDRD 77 . \64 . 

.UDRD £ DRAU I UH I TE ) \ 0 
.UDRD 0\0 

.UORD £ DRAU I GREEN ) \0 
.UORD 87 . \50 . 

.UDRD £ DRAU I RED ) VO 
.UORD 94.X34. 

.UDRD ( DRAU 1 P INK ) \0 
.UDRD 0\0 

.UORD £ DRAU I UHITE ) \ 0 
.UDRD 98 . \ 1 7 . 

.UDRD (DRAU I BLUE) \0 
.UDRD 100. \0 
.UORD £ DRAU I YELLDU ) \0 
.UORD 0\0 

.UDRD £ DRAU I UHITE ) \ 0 
.UDRD 98 . \ - 1 7 . 

.UDRD £DRAU I GREEN) \0 
.UDRD 94.X-34. 

.UDRD ( DRAU I RED ) \0 
.UORD 0\0 

.UORD £ DRAU I GREEN ) \ 0 
.UDRD 87.X-50. 

.UDRD £ DRAU I YELLDU ) \0 
.UDRD 77 . \-64 . 

.UORD £ DRAU I P I NK ) \ 0 
.UORD 0\0 
.UDRD £ DRAU i RED) \0 
.UORD 64.W7. 

.UDRD £ DRAU I UHITE ) \0 
.UDRD 50.X-87. 
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.WORD 

( DRAW 1 RED ) \0 

.WORD 

0\0 

. UORD 

( DRAU 1 GREEN ) \0 

. UQRD 

34.X-94. 

. UORD 

( DRAU 1 YELLOW ) \0 

.WORD 

17.\-98. 

.UQRD 

( DRAU 1 UHITE ) \0 

.UDRD 

0\0 

.UDRD 

( DRAU 1 BLUE ) \0 

.UDRD 

O.N-IOO. 

.UDRD 

( DRAU 1 GREEN ) \Q 

.UDRD 

-17.\-98. 

.UQRD 

( DRAU 1 RED ) \0 

.UDRD 

0\0 

.UDRD 

( DRAW 1 UHITE ) \0 

.UDRD 

-34 . \ -94 . 

.UDRD 

(DRAUI YELLDU)\0 

.UDRD 

-50. \-87. 

.UDRD 

( DRAU 1 GREEN ) NO 

.UDRD 

0\0 

.UDRD 

( DRAU 1 PINK ) \0 

.UDRD 

-64. \-77. 

.UDRD 

( DRAU 1 UH I TE ) \0 

.UDRD 

-77 . \-64 . 

.UQRD 

( DRAU 1 RED ) \0 

.UDRD 

0\0 

.UDRD 

( DRAU 1 BLUE ) \0 

.UORD 

-B7 . \-50 . 

.UDRD 

( DRAU 1 UHITE ) \0 

.UQRD 

-94.N-34. 

.UDRD 

( DRAU l GREEN ) \0 

.UDRD 

0\0 

.UORD 

( DRAU 1 RED ) \0 

.UORD 

-98 . \ “1 7 . 

• UDRD 

( DRAU 1 PINK ) \0 

.UORD 

-100. \0 

.UDRD 

( DRAU 1 UHITE ) \0 

.UDRD 

0\0 

.UDRD 

(DRAU 1 YELLOU) \0 

.UDRD 

-98 . \ 17 . 

.UORD 

( DRAU 1 GREEN ) \0 

.UQRD 

-94 . \34 . 

.UDRD 

( DRAU 1 UHITE ) \0 

.UDRD 

o.\o. 

.UDRD 

( DRAU 1 P INK ) \0 

.UDRD 

-87 . \50 . 

.UORD 

(DRAUI YELLDU)\0 

.UDRD 

-77 . \64 . 

.UDRD 

( DRAU 1 GREEN ) \0 

.UQRD 

0\0 

.UDRD 

( DRAU 1 RED ) \0 

.UDRD 

-64 . \77 . 

.UDRD 

( DRAU 1 UHITE ) \Q 

.UDRD 

-50 . \87 . 

.UORD 

( DRAU 1 YELLDU ) NO 

.UDRD 

0\0 

.UDRD 

( DRAU 1 P INK ) \0 

.UORD 

-34 . \ 94 . 

.UDRD 

( DRAU 1 GREEN ) \0 

.UDRD 

-17.X98. 

.UDRD 

( DRAU 1 UHITE ) \0 


VL2 : 

VL4 : 
VLB: 
REG1 : 
REG2 : 
REG3 : 
RECLIST 


ATT ADI : 


9 

SHADE: 


COUNT: 


.UORD 

0X0 

.UORD 

( DR AU 1 RED ) \0 

.UORD 

0.X100. 

.UORD 

(DRAUIGREENIEDL)XO 

.BLKU 

120. , 0 

-BLKU 

120. , 0 

.BLKU 

120. ,0 

.UORD 

0X0 

.UORD 

0X0 

.UORD 

0X0 

.UORD 

0X1 

. UDRD 

0X0 

.UORD 

410. X499. 

.UORD 

( BLACK 1 EOL ) \0 


ATTRIBUTE TABLES FDR CHARACTERS 

.WORD 0 
• UORD 0\0 

. UQRD 0\0 

-UORD QUOOOOO 
.UORD 100X10200 
.UORD 0 


SHADE TABLE 

.UORD 0X0 
.UORD 0X377 
.UORD 0X31714 
.UORD 0X63231 
.UORD 0X114546 
.UORD 0X146063 
.UORD 0X177400 
.UORD 63X146000 
.UORD 146X114400 
.UORD 231X63000 
.UORD 314X31400 
.UORD 314X0 
.UORD 314X63 
.UORD 231X146 
.UORD 146X231 
.UORD 63X314 
.UORD 0X377 
. BLKU 239 . , 0 


FRAME COUNTER MEMORY LOCATION 

.UORD 0X0 
.END 


; RED 


; GREEN 


; BLUE 


; START ADDRESS OF FONT TABLE 
; CHAR UIDTHXHEIGHT 
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Table 1. Character Draw Times for New Microcode 


Character 

size, 

pixels 

Character draw time, //sec, 
with erase on 

Character draw time, //sec, 
with erase off 

Character on 
32-pixel 
boundary 

Character offset 
from 32-pixel 
boundary 

Character on 
32-pixel 
boundary 

Character offset 
from 32-pixel 
boundary 

10 X 14 

46 

53 

24 

34 

20 x 28 

147 

222 

108 

195 

32 x 32 

217 

! 

366 

165 

295 


Table 2. Comparison of Character Draw Times Between New 
and Original Character Commands Using Autoclear To Erase 


New 

character 

size 

Draw time, //sec, with 
new character command 

Draw time, //sec, with 
original character command 

Character on 
32-pixel 
boundary 

Character offset 
from 32-pixel 
boundary 

Original 

character 

size 

Character at any 
position 

10 x 14 

24 

34 

10 x 16 

280 

20 x 28 

108 

195 

20 x 32 

680 

32 x 32 

165 

295 

32 x 32 

900 







Figure 1. Primary flight display of Advanced Concepts Simulator. 




Figure 2. Block diagram of RDS 3000. 
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Write mask 


PONG 

buffer 
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planes 


PING 

buffer 
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video 
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video 


Figure 3. Double-buffering, crossbar switches, and masks. 
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Set XBS to 


display 
new PING 
buffer 


Turn on 
autoclear 


V 


1 


Turn off 
autoclear 




BPS 

processor 


T 


Erase PONG buffer, 
no other processing 
going on 

(requires one video frame 
interval) 


Set XBS to 
display 

new PONG buffer 

— , i 


Draw everything for next 
frame into PONG buffer 


MAI 024 
processor 


4 


Transform 
coordinates 
for next frame 


Figure 4. Processor activity during frame update using original sequential code and autoclear. 
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Set XBS to 


Set XBS to 
display 
new PING 


Turn on 
autoclear 


Turn off 
autoclear 


display 
new PONG 
buffer 



Erase PONG buffer, 
BPS working with 
MAI 024 to do 
transformations 
(requires one video 
frame interval) 


Draw everything 
for next frame 
into PONG buffer 


MAI 024 
processor 



Transform coordinates 
for next frame 

Figure 5. Processor activity during frame update with coordinate transformations computed during 
autoclear interval. 
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Set XBS to 
display 
new PING 
buffer 


Y 


BPS 

processor 


Turn on 
autoclear 


Turn off 
autoclear 



Pass parameters 
to AGG4 and 
start it 


Set XBS to 
display 
new PONG 
buffer 


T 


Erase PONG buffer, 
BPS working with 
MAI 024 to do 
transformations 
(requires one video frame 
interval) 



*0 *1 


l 2m 


Draw vectors, 
polygons, etc., 
into PONG buffer 


AGG4 

processor 



Draw 

characters 
into PONG buffer 


MAI 024 
processor 



Transform coordinates 
for next frame 

Figure 6. Processor activity during frame update with coordinate transformations computed during 
autoclear interval and AGG4 drawing characters. 
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Set XBS to 


Pass parameters 


Draw vectors, polygons, 
etc., into PONG 



PONG buffer 



into PONG buffer 


MAI 024 
processor 



Transform 
coordinates for next 
frame 

Figure 7. Processor activity during frame update using selected area erase, with coordinate transforma- 
tions for next frame computed simultaneously with character generation by AGG4. 
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Increasing k value 


Pixel in 
slice 

Increasing 
n value 


9876543210 


0 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 
11 
12 

13 

14 

15 
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Figure 9. Bit-mapped character generation. 
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Figure 10. Barrel shifter and inserter output register. 
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Figure 11. Data flow through the barrel shifter with offset of 4 bits. 
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Figure 12. Data flow through the barrel shifter with offset of 20 bits. 
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Figure 13. Font bit manipulation for several FBM offsets. Locations of inserter output register left masks 
(lm) and right masks (rm) are also shown. 
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Figure 14. FBM writes for first two pixel locations. 
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Figure 15. Character erase and draw. 
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